--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Mike,
>
> Yes the 3 Rod Gizmo works with standard GCode which may include long linear constant speed feeds.
>
>
> Yes you should be able to enter your formulas and run.
>
> Do you have a robot?  Maybe for Xmas?
>
>
> Happy Holidays!
> TK
>
>
>
> ________________________________
> From: michaelthomasn <michaelniksch@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, December 24, 2012 7:59 AM
> Subject: [DynoMotion] Re: Robot Arm Control
>
>
>  
>
> Tom,
>
> Thanks again....That is very interesting.
>
> Does the 3 rod machine operate from standard Gcode, then?
>
> It seems as if the inverse kinematic formulas that I came up with for the arm could be used directly in Kmotion along with the maximum length function to eliminate the need for me to convert the linear sections of code into segments.
>
> Maybe I am misunderstanding?
>
> Currently, I have a spreadsheet set up so that I can type in any x,y,z,a,c coordinate, and it will give me all of the angles needed to get there with the arm.
>
> Mike
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Mike,
> >  
> > To do non-linear Kinematics with KMotion you must create a C++ Kinematics class with the mapping formulas for your system.  See the Kinematics3Rod.cpp module as an example.  Your can also set the MaxLinearLength for your system there.
> >  
> > You shouldn't really have to worry about the feed rates of your motor axes.  That should all be handled naturally.  The GCode specifies the feed rate in normal xyz CAD space.  So basically this defines points and times in CAD space that will provide the desired feed rate.  These points are then mapped into your robot "Actuator" space.  So the result is that if the Atuators all move to those weird positions at the appropriate times (with linear interpolation in between), the xyz motion will be at the desired rate. 
> >  
> > Another issue that is handled for you is the maximum velocity and acceleration constraints.  Typically the Motor Actuators will have a fixed maximum acceleration and velocity.  However how this relates to max acceleration and velocity in CAD space is varying depending on position and direction.  The Coordinated Motion Library handles this problem by numerically taking the derivative of your provided mapping formulas.  This allows the automatic determination of the limiting actuator and the mapping of the limit back to CAD Space.  In this way the velocity and acceleration through CAD space used by the Trajectory Planner will always be optimal and within the capabilities of your motor axes.
> >  
> > This is actually also present in standard xyz linear systems.  The maximum allowed velocity and acceleration is greater when moving along a diagonal with more than one axis moving together as opposed to moving a single axis. 
> >  
> >  
> >  
> > Regards
> > TK
> >  
> >  
> >  
> >
> >
> > ________________________________
> > From: michaelthomasn <michaelniksch@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Saturday, December 22, 2012 8:56 PM
> > Subject: [DynoMotion] Re: Robot Arm Control
> >
> >  
> > Tom,
> >
> > Thanks for the response.
> >
> > 1000 segments per second seems plenty fast. I see what you mean about maybe not needing such a low segment distance.
> >
> > I'm not really following your paragraph about the mMotion Params. What is it that defines the maximum length? Is that a user value?
> >
> > I'm a little confused as to how I might translate feed speeds into robot motion, too. I would like to, of course, retain ipm feed for the robot arm, but haven't gotten my head around a way that I could reliably get multiple angular axis' movement to follow a specific ipm.....especially since the arms position is so critical.
> >
> > Mike
> >
> > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Mike,
> > >
> > > Good questions. The motion should be smooth.  As you note the situation is really no different then doing "3D jobs" in a standard xyz mill where there is an arbitrary 3D path in space that consists of small line segments.  I doubt if you will require the segments to be only 0.005" long.  But it depends on your accuracy requirement and the curvature of the path - or non-linearity of the kinematics.  KFLOP can process over 1000 segments/sec on a sustained basis.  I haven't seen a case where this is inadequate.   It works out because tight curvature requires smaller segments, but machine acceleration limits reduces speed through tight curves, so the segment rate remains manageable.
> > >
> > > A while ago I made an Excel Spreadsheet (attached) to help myself understand the accuracy/segment length/lookahead issues.  Here are some results:
> > >
> > > For Curvature of Radius=0.1 inches, accuracy of 1mil, segments can be 40
> > > mils long. 
> > > For Curvature of Radius=0.1 inches, accuracy of 0.1mil, segments can be 13
> > > mils long. 
> > > A system with 0.1G acceleration can go 120ipm through such a
> > > curve.
> > >
> > > There is a parameter m_MotionParams.MaxLinearLength that specifies the maximum length of a segment.  So for example if a 10 inch linear feed is specified in the GCode it will be automatically internally subdivided to be less than this length so the Kinematic calculations and constraints are all applied to the intermediate points/segments.
> > >
> > > There isn't any fixed limit on GCode size for KMotionCNC other that what is practical on the PC.
> > >
> > >
> > > HTH
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: michaelthomasn <michaelniksch@>
> > > To: mailto:DynoMotion%40yahoogroups.com
> > > Sent: Saturday, December 22, 2012 1:21 PM
> > > Subject: [DynoMotion] Robot Arm Control
> > >
> > >
> > >  
> > > Hi Tom,
> > >
> > > A little while back I was thinking about a retrofit of a Kuka robot. My friend bought the thing used, and we found out later that the thing had about 15 times the hours on it as was listed. He sent the thing back to the seller and got his money back. So that project kinda stalled out.
> > >
> > > In the meantime, I have gotten pretty interested in the robot stuff and have been working on an inverse kinematics solver that could convert regular 3 to 5 axis mill code to useful robot code. So far, I have only gotten an excel spreadsheet working to solve the inverse kinematics.....and it has a little more refinement needed to get the wrist rotation 100% correct every time.
> > >
> > > After working on this for a little bit, I realized that there is no such thing as a linear movement to a robot.....at least not without coordinated movement of many axis'. The only thing i have been able to come up with is to break down all movements to very small segments to achieve a linear move.....like maybe .005" or something. This is obviously going to create some really lengthy Gcode......even for pretty simple moves.
> > >
> > > It seems that commercial robots have linear and arc functions built in to the control that would reduce Gcode size demands and simplify things on the user end.
> > >
> > > My questions are......is there a Gcode line limit in Kmotion CNC?
> > >
> > > And.....how smooth could i expect a linear move of say 10 inches if the gcode was written as .005" or less segments? I guess I just want to know if it would likely be stuttery. I'm asking because I'm considering building a 5 axis robot arm for myself....and I'm really not sure what I should expect at this point.
> > >
> > > I see some pretty smooth movement in 3d code, and that is changing directions of the z axis pretty often.....whereas this robot scenario would not be.
> > >
> > > I hope I have explained myself well enough
> > >
> > > Mike
> > >
> >
>